My hope was you could use (room) account data, but that doesn't have a "state key" or anything. I think it also limits you in size, which probably wouldn't work. 😢

I was also thinking of account data and I believe it isn't subject to the 64KiB limit?

What were you planning to use a state key for with thread subscriptions?

Using account data in this way may not have the 64 kiB limit, but ideally we should try to avoid using it in more places that will make it hard to add that limit. (Since the lack of a limit is a mistake, I believe.)

The two problems I noted above are the main reasons I don't like using account data here:

• The read-modify-write issue
• Clients and servers having to operate on whole lists when they only care about one tiny portion of it.

I think Patrick's 'state key' mention is along the lines of: 'we only have a single key for each piece of room account data: the type'.
You could imagine using having an extra key, so room account data could be keyed on (m.thread.subscription, $abc123def456).

Or we could stretch things further to have 'Event Account Data' or something.

I think Patrick's 'state key' mention is along the lines of: 'we only have a single key for each piece of room account data: the type'.
You could imagine using having an extra key, so room account data could be keyed on (m.thread.subscription, $abc123def456).

Oh, I see.

Since the lack of a limit is a mistake, I believe.

Correct.

And your example of a state keys is spot on for what I was thinking.

I wonder if expanding this to "relation subscriptions" would be helpful for any other use-cases. So a subscription is parent event+relation type?

Might not be super useful with the current relations though.

Does "banned" mean the sender is in the recipient's m.ignored_user_list?

I meant banned from the room, but the mentioning user getting ignored by the mentioned user also sounds like a good case to apply this!

This sounds like it might either be expensive or leave dangling subscriptions. If the server exposed an API to list all thread subscriptions in the room, clients could use /relations to only walk the subscribed threads which might be more efficient?

The idea would be that through MSC4308 (or another mechanism) the client will already know its active subscriptions, so indeed it can just walk the (recently- and automatically-)subscribed threads.

However it's hard to give a general definition of 'time' to describe how much the client should consider, so it's left purposefully flexible here.

I would make optional this Reversal of automatic subscriptions. This add complexity client side for a low gain.

This is relevant to not subscribe if the mentioning user has been banned or ignored before the client takes into account the mention to set up the subscription.

I would let the user reverse manually the automatically subscribed thread if any

An API listing active subscriptions per room might also make unsubscribing easier?

I'm kind of surprised there's no changes to the /threads API?

When a user mutes a room, it puts an override rule in for that room. And this override rule is the highest priority

So this is not possible to receive notification from a thread in a muted room.
The manual subscription should be disabled in this room at the UI level until the end user unmutes the room.
When a room is muted, the client should pursue the automatic thread subscriptions. These subscriptions will be ignored until the room is unmuted Keep managing the automatic subscription eases the potential switch mute/unmute of a room. The client UI should let the end user know any potential thread subscription is disabled in a muted room

Why isn't there an endpoint to paginate all thread subscriptions in a room? (my expectation)

Similar to how clients back-paginate with messages in a room by starting with /sync and then using /messages to get the rest as necessary.

Ok, I think some interactions can lead to "stuck" subscriptions now 🙃

Imagine the following scenario.

• On device 1, I have a thread containing events E1, E2 (which mentions me), and E3.
• Because of E2, my client subscribed me automatically to the thread.
• Now, I decide that I don't want to be subscribed to the thread, so I manually unsubscribe from it.
• I open device 2, and back-paginate the thread there as well.

I think that, on device 2, because there's no data related to the thread subscription anymore, when device 2 will see E2 for the first time, it will automatically re-subscribe me to it.

Am I missing something that would prevent this stuck subscription behavior?

Ok, if I'm not mistaken, then. One feature that we'd like to allow, is re-subscription after a thread has been unsubscribed. That is, in my example, if E4 mentions me again, my client should be able to subscribe me again.

I thought we could use some kind of conceptual enum with 3 variants:

• subscribed
• unsubscribed
• (nothing)

Unsubscribing would lead to the unsubscribed state, instead of deleting the subscribed state and replacing it with nothing. Then, we'd need a rule like "if unsubscribed, don't subscribe me again".

But… that doesn't work either 🫠 When E4 comes, which mentions me, my client might want to re-subscribe me to the thread. If we have a rule like "if unsubscribed, don't ever subscribe me ever again", then I can't be re-subscribed. The real information is "I'm unsubscribed until E3 included"; all events prior to it should not lead to a new automatic subscription, and all events after it should automatically resubscribe me. As a matter of fact, I think including the event id in the unsubscribe variant should be sufficient…

…Now, if you're paying attention, I've said "events" and "after" in the same sentence. I'm talking about event ordering here, hence I'm afraid we might run into the "stuck notification" problem, because the ordering may be different if events have been received from sync ("stream" ordering) or from /relations (topological ordering). Here are a few ideas, how to solve it:

• maybe the "unsubscribe" event id could be… two event ids at most: one in topological ordering, one in sync ordering, and it's the client which determines which is last, in its local state. In this case, the server should accept multiple values at the same time, for the "unsubscribe" endpoint. That's an idea that was mentioned to solve the stuck read receipts dilemma in the past by @MadLittleMods if I recall correctly, so it could apply here too.
• maybe we should enforce one ordering over the other, and say that this one ordering is the correct one. In that case, it must be the topological ordering, since the sync ordering doesn't match from one device to another. I'm afraid this would lead to the stuck notifications issue, though, unless clients agreed to only use /relations for filling the content of a thread.
• MSC4033 gives some stable-ish event ordering, and it could be used for determining the order of subscriptions.
• We could actually use the user's own read receipts as a proxy of "unsubscribed until this event": only event after the read receipt could cause an automatic re-subscription. This is messy though, as it implies a processing ordering dependency in clients: the client would need to process read receipts after it's processed thread subscriptions.

MSC4033 would honestly be the most satisfying, but it's been stuck for a while, there's been valid objections in it, etc. I would be curious to hear other people's ideas or thoughts about the problem. Am I missing something here?

I agree with the need to introduce a new variant unsubscribed to have the possibility to differentiate undefined with unsubscribed.

Then to keep thread subscriptions as simple as possible. I would suggest to disable automatic subscription in a thread which has been manually unsubscribed. I will receive the potential new mentions in this thread but this will not subscribe me again because I clearly unsubscribed myself from this thread

Note: I would manage differently manual and automatic unsubscription (if automatic is planned)

• a manual unsubscription -> unsubscribed state (via a PUT)
• an automatic unsubscription -> undefined state (via a DELETE)